Field of the Invention
The invention relates to local IP access, also known as LIPA. LIPA is a feature of mobile communication networks, which was introduced in Release-10 of 3GPP (see in particular section 5.7.1 of 3GPP TS 22.220 V10.0.0, 2009-09).
Discussion of the Related Art
With the progressive convergence of the Internet world and of the telecommunications world, most services that are offered on the Internet become available on mobile phones, and conversely voice services become available through the Internet (Voice over IP). In addition, fixed-mobile convergence aims at proposing single communication devices able to connect both to a cellular network (e.g. when travelling) and to a local network (such as a home network, when at home, or a corporate network, or a hotspot). While fixed-mobile convergence is not yet a widespread reality, many communication devices already have both a radio interface to connect to cellular networks, and another radio interface to connect to a local network. Most often the two radio interfaces are used independently though (i.e. the user selects manually, either explicitly or implicitly, which radio technology he wants to use). Having two radio interfaces forces the communication device to embed two different radio technologies (e.g. WLAN interface and cellular radio interface), which is more expensive, takes more space (while size and weight are important characteristics), and consumes a lot of energy since two radio interfaces need to be powered, which reduces the autonomy of the communication device (and also reduces battery life).
Cellular networks are very convenient because they offer an extremely broad coverage (for example a GSM user can typically make phone calls from almost anywhere in the world). However, their bandwidth is typically rather low compared to the bandwidth offered to users of local networks (which are typically connected to the Internet through rather high speed connections such as fiber, DSL or cable, for home networks). In addition, they are in general more expensive to use. Despite their extensive coverage, cellular networks are not always available, for example they are not available in certain remote locations (such as certain rural areas, or certain very small villages), or indoor locations not reachable by the cellular network's signals (basements, rooms surrounded by several layers of walls, etc.).
Small cellular base stations called femtocells can be used to mitigate the unavailability of cellular networks, as long as an alternate network access (typically a wired network) is available. Femtocells can typically be simple devices installed by end users themselves. Femtocells behave like a cellular network with respect to communication devices (which can use their regular cellular network radio interface to communicate with them), and connect to a cellular network operator's core network through the alternate network access (such as Internet access via fiber, DSL or cable subscriptions). Femtocells can be developed for any types of cellular networks technologies, for example WCDMA, GSM, CDMA2000, TD-SCDMA, WiMAX or LTE technologies. The 3GPP refers to 3G femtocells as Home Node Bs (HNBs), and in LTE the proper terminology for a femtocell is Home eNode B (HeNB). Femtocells are in fact “home” cellular base stations.
In the context of fixed-mobile convergence of voice services, the use of femtocells is an advantageous alternative to the embedding of two different radio technologies in a communication device, since the communication device becomes simpler to implement, can be smaller, lighter, cheaper, and have a better battery autonomy.
LIPA goes one step further and aims at providing access from a communication device to a home-based network (for any kind of IP based services, not only for voice) through a femtocell. A home-based network is in fact any kind of local network (e.g. it can be in a residential or corporate environment, or a public hotspot), i.e. it is not necessarily a network in the home of an individual (the term “home” has to be understood in a broad sense, the same applies to other expressions such as “home” cellular base station).
Although an initial specification of LIPA is already available, LIPA is still being specified as not all issues have been addressed. LIPA is therefore the subject of standardization efforts at 3GPP. Many aspects of LIPA are still expressed as goals to be achieved, without indications on how to achieve these goals.
One class of LIPA solutions that are currently under study in 3GPP is referred to as the “solutions relying on Local Packet Data Network (PDN) connection”. With this type of solutions there are several open issues.
The technical report 3GPP°TR°23.8xy v0.2.0 (“Local IP Access and Selected IP Traffic Offload”) is a study of architectural solutions for LIPA to the home-based network from a femtocell (Home NodeB or Home eNodeB), as well as a study of architectural solutions for Selected IP Traffic Offload (SIPTO) for both femtocells and macrocells. The number 23.8xy was a temporary name for the technical report on LIPA when the first patent application (U.S. 61/375,016) which priority is claimed in the present patent application was filed (Nov. 2, 2009). It was later assigned a permanent TR number by the 3GPP administration (TR 23.829). All versions of this document are stored under the permanent name on the 3GPP web site. TR°23.829 v0.2.0 was updated by technical contributions submitted to 3GPP by the inventors of the present invention, after the priority date of the present application. The LIPA solutions under study in this technical report when the first priority application was filed can be broadly summarized in two categories. The first one relates to solutions based on traffic breakout performed within H(e)NB using a local PDN connection, and the second one relates to solutions relying on a NAT (Network Address Translation) device. The first category is of particular interest in the context of the invention. The technical report was still in study phase and did not contain any full-blown architecture figure agreed in the standard at the priority date of the present application. Instead it contained a list of architectural requirements, architectural principles and a list of open issues and proposed solutions to such issues. FIG.°1 highlights some of the possible architecture requirements for a LIPA solution for HeNB using a local PDN connection according to the technical report.
The following are possible LIPA requirements according to FIG.°1. A Local PDN Gateway (L-GW) function is collocated with the HeNB (for example it can be embedded in the HeNB, or each function can be embedded in a corresponding device, both devices being in the same geographical location). The local PDN Gateway provides direct IP access to the home-based IP network. The Mobility Management Entity (MME) and Serving GateWay (SGW) nodes are located in the operator's Evolved Packet Core (EPC). A Security Gateway (SeGW) node is located at the edge of the operator's core network; its role is to maintain a secure association with the HeNB across the IP backhaul network that is typically owned by a different provider and is therefore considered insecure. A Home router (which typically behaves as a NAT device) is located at the boundary of the home-based IP network and the IP backhaul network, as typically found in DSL or cable access deployments today. It is also possible to have an element (optional), depicted in FIG.°1 consisting of an external PDN Gateway (PGW) located in the operator's core network. This element may be used when the user needs to access services provided by the operator, in parallel to accessing the home-based network.
3GPP TR 23.8xy v0.2.0 identifies the following open issues with the type of architectures described above.
One issue that needed to be solved in this context included the definition of signaling information needed for establishment of optimal data path (this is referred to as “optimal routing” or “optimized routing information issue”). More particularly, for active UEs, there was a need to find mechanisms to optimize the routing of the EPS/UMTS bearers used for LIPA traffic, allowing the user plane to bypass the Core SGW and SGSN. What was still unanswered was in particular the type of information that can be used by the HeNB and the L-GW in order to establish the direct path (“optimized routing information issue”). Specifically, for a specific UE, the kind of information that could be used by the HeNB to discriminate between uplink packets destined to the home-based network (i.e. the L-GW) and uplink packets destined to the external PGW was unknown. For a specific UE, the kind of information to be used by the HeNB to map the downlink packets received from the L-GW on the appropriate Radio Bearers was also unknown.
Another issue lies in the fact that the proposed solution is expected to work when the local breakout point (L-GW) is located in a private address domain, e.g. behind a NAT gateway (this is referred to as the “NAT issue”, or “operation behind a NAT device”).
How to assist the backhaul operator to perform legal intercept is another issue (referred to as the “Lawful Intercept issue”).
How paging works in this architecture was still an open issue, as per the following excerpt from TR°23.8xy: “it is FFS whether IDLE mode downlink packet buffering and initiation of network triggered service request procedure should be local to the H(e)NB, leading to two SGWs per UE (one in Core Network and one in H(e)NB subsystem or transport backhaul network), which is not in line with current TS 23.401 architecture principles, or whether this function should be in the Core Network”.
Starting from Release 99, the 3GPP specifications make provisions for access to a private enterprise network (intranet) from any macro cell. This is often referred to as network-based VPN access.
With LIPA it becomes possible to access the enterprise network from a femtocell, in a way that all traffic bound to/from the enterprise network is routed locally, without leaving the enterprise.
A major difference between the macro versus femto scenarios resides in the Gateway that represents the ingress point to the intranet. In the macro scenario the terminal establishes a Packet Data Network (PDN) connection to a PDN Gateway (PGW) that is part of the operator's Evolved Packet Core (EPC) and has pre-established a layer 2 tunnel to an ingress point in the intranet. In contrast, in the femtocell scenario the terminal establishes a connection to a Local Gateway (L-GW) residing inside the enterprise network.
Assuming that the same Access Point Name (APN) is used to access the enterprise network in both cases, some additional information is required in order to assist the EPC in selecting the right gateway, depending on whether the terminal is establishing the connection from the enterprise's femtocell or from somewhere else.
FIG. 2 depicts a scenario where the UE can access the Enterprise network via either a macro cell (eNodeB—eNB) or a femto cell (Home eNodeB ? HeNB).
For VPN access via a macro cell the signaling path for PDN connection establishment is illustrated with an arrow going from the UE to the PGW (with two solid lines). Based on the PDN connection request received from UE, the Mobility Management Entity (MME) checks the APN requested by UE against its subscription record in the HSS, as described in 3GPP TS 23.401 (“Evolved Packet Core for 3GPP access”). If the UE is authorized to access the requested APN, the MME performs PGW selection relying on DNS resolution of the APN-FQDN i.e. a Fully Qualified Domain Name that is constructed with the APN substring, as specified in 3GPP TS 23.003 (“Numbering, Addressing and Identification”) and 3GPP TS 29.303 (“Domain Name System Procedures; Stage 3”).
For instance, if the APN for VPN access is “companyABCvpn”, the corresponding APN-FQDN, used for DNS resolution, will typically be constructed as: “companyABCvpn.epc.mnc015.mcc234.3gppnetwork.org”.
In contrast, for enterprise access via LIPA, the signaling path for PDN connection establishment is depicted with an arrow going from the UE to the L-GW (with two dotted lines). In this case the MME would need to override the usual DNS resolution based on APN-FQDN and perform L-GW selection based on information other than, or in addition to, the APN.
At the time the first priority application was filed, there were two alternatives for L-GW selection described in 3GPP TR 23.829 v1.1.0 (“LIPA and SIPTO”), but there was no agreement yet which one should be standardized. The first proposal is to have the L-GW address signaled from the RAN (Radio Access Network, i.e. from the HeNB). The other proposal is to use DNS based resolution with an FQDN that contains the CSG identifier of the femtocell.
For sake of simplification, FIG. 2 makes the assumption that the Serving Gateway (SGW) is located outside of the Enterprise network, even for LIPA access. While this is a possibility, it is more likely that for LIPA access the system would select a SGW that resides inside the Enterprise network (L-SGW in FIG. 3) and is collocated with the L-GW, as depicted in FIG. 3.
The current solution is problematic when the same APN may be used to access the Enterprise network via both a macrocell and a femtocell. Indeed, the Mobility Management Entity (MME), which performs the PGW/LGW selection, does not know which gateway to select since it depends on whether the terminal is requesting PDN connection establishment from the Enterprise femtocell or from somewhere else. The APN may be identified as being “LIPA only”, “LIPA prohibited”, or “LIPA conditional”, but without regard to the CSG from which the PDN connection request originates.
The MME is aware whether the terminal is inside a femtocell, thanks to the CSG ID that is provided by the RAN in all UE-associated signaling messages. However, the user's subscription record in the HSS (at the time the first priority application was filed)provides no information about possible linkage between the requested APN and the CSG ID of the femtocell where the UE is currently residing.
If the MME selected the Enterprise L-GW whenever the UE requests the Enterprise APN from a femtocell, this would lead to the error case depicted in FIG. 4. Namely, consider the scenario where the user requests a PDN connection to the Enterprise APN via its home (residential) femtocell. In this case the MME must not select the L-GW residing in the Enterprise network (arrow going from the UE to the L-GW, with two dotted lines), instead it must select the PGW (arrow going from the UE to the PGW, with two solid lines), in the same manner as if the UE were in a macrocell.
Table 5.7.1-1 of 3GPP TS 23.401, which describes certain HSS data, is also useful for the understanding of the invention, and is reproduced below:
FieldDescriptionIMSIIMSI is the main reference key.MSISDNThe basic MSISDN of the UE (Presence of MSISDN isoptional).IMEI/IMEISVInternational Mobile Equipment Identity - Software VersionNumberMME IdentityThe Identity of the MME currently serving this MS.MME CapabilitiesIndicates the capabilities of the MME with respect to corefunctionality e.g. regional access restrictions.MS PS Purged from EPSIndicates that the EMM and ESM contexts of the UE aredeleted from the MME.ODB parametersIndicates that the status of the operator determined barringAccess RestrictionIndicates the access restriction subscription information.EPS Subscribed ChargingThe charging characteristics for the MS, e.g. normal, prepaid,Characteristicsflat-rate, and/or hot billing subscription.Trace ReferenceIdentifies a record or a collection of records for a particulartrace.Trace TypeIndicates the type of trace, e.g. HSS trace, and/or MME/Serving GW/PDN GW trace.OMC IdentityIdentifies the OMC that shall receive the trace record(s).Subscribed-UE-AMBRThe Maximum Aggregated uplink and downlink MBRs to beshared across all Non-GBR bearers according to thesubscription of the user.APN-OI ReplacementIndicates the domain name to replace the APN OI whenconstructing the PDN GW FQDN upon which to performDNS queries. This replacement applies for all the APNs in thesubscriber's profile.RFSP IndexAn index to specific RRM configuration in the E-UTRANURRP-MMEUE Reachability Request Parameter indicating that UEactivity notification from MME has been requested by theHSS.CSG Subscription DataThe CSG Subscription Data is a list of CSG IDs perPLMN and for each CSG ID optionally an associatedexpiration date which indicates the point in time when thesubscription to the CSG ID expires; an absent expirationdate indicates unlimited subscription.Each subscription profile contains one or morePDN subscription contexts:Context IdentifierIndex of the PDN subscription context.PDN AddressIndicates subscribed IP address(es).PDN TypeIndicates the subscribed PDN Type (IPv4, IPv6, IPv4v6)APN-OI ReplacementAPN level APN-OI Replacement which has same role as UElevel APN-OI Replacement but with higher priority than UElevel APN-OI Replacement. This is an optional parameter.When available, it shall be used to construct the PDN GWFQDN instead of UE level APN-OI Replacement.Access Point Name (APN)A label according to DNS naming conventions describingthe access point to the packet data network (or awildcard) (NOTE 6).EPS subscribed QoS profileThe bearer level QoS parameter values for that APN's defaultbearer (QCI and ARP) (see clause 4.7.3).Subscribed-APN-AMBRThe maximum aggregated uplink and downlink MBRs to beshared across all Non-GBR bearers, which are established forthis APN.EPS PDN SubscribedThe charging characteristics of this PDN Subscribed contextCharging Characteristicsfor the MS, e.g. normal, prepaid, flat-rate, and/or hot billingsubscription. The charging characteristics is associated withthis APN.VPLMN Address AllowedSpecifies whether for this APN the UE is allowed to use thePDN GW in the domain of the HPLMN only, or additionallythe PDN GW in the domain of the VPLMN.PDN GW identityThe identity of the PDN GW used for this APN. The PDNGW identity may be either an FQDN or an IP address. ThePDN GW identity refers to a specific PDN GW.PDN GW Allocation TypeIndicates whether the PDN GW is statically allocated ordynamically selected by other nodes. A statically allocatedPDN GW is not changed during PDN GW selection.PLMN of PDN GWIdentifies the PLMN in which the dynamically selected PDNGW is located.Homogenous Support of IMSIndicates whether or not “IMS Voice over PS Sessions” isOver PS Sessions for MMEsupported homogeneously in all TAs in the serving MME.List of APN - PDN GW ID relations (for PDNsubscription context with wildcard APN):APN - P-GW relation #nThe APN and the identity of the dynamically allocatedPDN GW of a PDN connection that is authorised by the PDNsubscription context with the wildcard APN. The PDN GWidentity may be either an FQDN or an IP address. ThePDN GW identity refers to a specific PDN GW.